The SSL protocol, originally developed by Netscape Communications, has been universally accepted as a means for authenticated and encrypted communication between clients and servers over the Internet. The SSL protocol can be used to secure various application protocols, such as HTTP over SSL (HTTPS), IMAP over SSL (SSL), FTP over SSL (FTPS), etc. One of the goals of SSL is to prevent so-called “man-in-the-middle” attacks. The “man in the middle” can be regarded as a rogue computer that attempts to insert itself in communications between a client and a server. Where secure communications are employed, the rogue attempts to intercept the legitimate cryptographic keys that are passed back and forth during the SSL exchange, substitute its own keys, and make it appear to the client that it is the server, and to the server that it is the client. This is accomplished by the rogue exchanging its own keys with the client and server, allowing the rogue to establish its own session keys for use with the real server and client. Thus, the rogue not only is able to read all the data that flows between the client and the real server, but also to change the data without being detected.
To counter the man-in-the-middle threat, an important part of the SSL authentication process requires that a client check that the domain name in the server's certificate corresponds to the actual domain name of the server with which the client is attempting to communicate (this is in addition to checking the validity of the certificate by performing other steps in the authentication process). This is done using the server's digital certificate, a certification (issued by a trusted third party known as a certificate authority or CA) that a particular cryptographic key, known as the server's “public key” is associated with the server identity specified in the certificate (e.g., the server's web address). That is, the CA validates the association between the owning entity (the server) and the public key.
Once the client and (optionally) the server is/are satisfied that each is the computer it claims to be, the client and server can exchange session keys. These are additional cryptographic keys that are used to encrypt the data transfers between the computers from then on. Thus, the SSL protocol provides for both authentication and encryption, and has built in safeguards to prevent third parties' computers from snooping on communications between a client and a server.
Sometimes, however, such snooping is not malicious. For example, Internet devices known as proxies are often used as “men-in-the-middle” to act as caches, content filters, virus filters, etc. Where SSL is used, however, such proxies are unable to participate in the communication stream (because the SSL protocol itself is designed to ensure they cannot). This presents a problem where there are legitimate reasons for a proxy to intercept SSL communications and it is therefore desirable to have a scheme for overcoming such difficulties.
US PGPUB 2007/0038853 (hereinafter, the “'853 publication”) describes one proposal for allowing a proxy to intercept SSL communications. In this scheme, a server-side accelerator intercepts an SSL connection request from a client to a server and establishes a secure connection between itself and the client. Later, the server-side accelerator provides the symmetric keys and cipher information to a client-side accelerator, which allows the client-side accelerator to assume control of the secure connection with the client. Such a solution does not provide a server-side accelerator that is transparent to the server. Instead, the server-side accelerator is explicit insofar as the server is concerned because the server sees SSL packets that were generated at the server-side accelerator.